These explicit casts are needed because NetworkService overloads differ only by failure type. This is brittle and can hide type mismatches at runtime. Consider renaming the overloads (e.g. requestErrorResponse vs request) or using a generic error wrapper so call sites don’t require forced casts.

then and SnapKit (.snp) are used in this file, but only UIKit is imported. This won’t compile unless you add the needed imports (e.g. Then/SnapKit) or remove the usages.

The copy says "개발 중인 페이지입니다" which reads like a “work in progress” page, but this view is presented on 5XX server errors per the PR description. Consider updating the title/subtitle to a maintenance/outage message so users aren’t misled.

then is used later when creating ErrorViewController, but this file doesn’t import Then. This will fail to compile unless Then is imported (or the .then usage is removed).

presentErrorViewController can be invoked on a background thread (the notification is posted from networking code). Presenting view controllers must happen on the main thread, and repeated 5XXs can trigger multiple presentations. Dispatch to the main queue and guard against presenting the error screen more than once.

Property name waringImageView looks like a typo (should be warningImageView). This makes the code harder to read/search and propagates throughout constraints/usages.

refreshToken() uses AF.request(api).publishDecodable(...).value() without .validate(), so non-2xx responses may be treated as successes if they decode. Add validation (or explicit status-code checks) so refresh only succeeds on 2xx.

Each retry stores a new AnyCancellable into subscriptions and never removes it. Over time this can grow unbounded (even though publishers finish). Consider removing cancellables on completion, or using a different approach that doesn’t retain every finished subscription.

Header comment says Retrier.swift but the file/class is Interceptor. This mismatch makes file navigation/search confusing; please update the header to match the filename.

createNotificationKeyword now falls back to createCoreDataKeyword for any error, which also inserts into CoreData and returns an error message implying login failure. This changes behavior for non-auth errors (e.g. 400/500/network) and can create unintended local keywords. Consider only falling back for specific cases (e.g. refresh failure / not logged in), and ensure the returned error message matches the actual failure.

ErrorViewController(...).then { ... } requires the Then library, but this file only imports UIKit. Unless there’s a module-wide re-export (none found), this will not compile. Add import Then here or avoid .then and set modalPresentationStyle directly.

presentErrorViewController() can be invoked from a background thread because the ServerError notification is posted from networking code. This method performs UIKit operations (present, dismiss, setViewControllers), which must run on the main thread. Wrap the body in DispatchQueue.main.async { ... } (or ensure the notification is delivered on the main queue).

File header comment says Retrier.swift, but the file/class is Interceptor. This can confuse future maintenance and file searches—please update the header to match the actual filename/type.

wrapperView is only centered inside wrapperViewLayoutGuide and its subviews are only constrained via centerX/vertical constraints. There are no leading/trailing (or width) constraints tying the content to a deterministic width, which can lead to ambiguous layout warnings and unexpected wrapping on different devices. Consider constraining wrapperView (or at least subTitleLabel) with leading/trailing insets and/or setting a max width relative to the safe area.

PR/issue description says this screen is shown on 5XX server errors (점검/장애 상황), but the UI copy here says “개발 중인 페이지입니다”. This looks like a mismatch with the intended maintenance page behavior; consider updating the title/subtitle strings to reflect a server 점검/일시적 오류 message.

The PR description/issue says this screen is shown for 5XX “점검 페이지”, but the UI copy here says “개발 중인 페이지입니다” and apologizes for a page under development. This is likely the wrong message for a server maintenance/outage state; please update the strings to match the intended 5XX maintenance context.

This second request(api:) has the same signature as the earlier one (only the Failure type differs). This is an invalid overload in Swift and will break compilation. Consider exposing a single public request API (e.g., always returning ErrorResponse) and providing a helper to erase/map to Error where needed.

statusCode was added to ErrorResponse without a default value / custom initializer. This changes the synthesized memberwise init and will break existing call sites like ErrorResponse(code:..., message:...) across the app. Consider giving statusCode a default (var statusCode: Int? = nil) or adding an explicit init with statusCode defaulting to nil to keep source compatibility.

The flag name isPresentingPresentErrorViewController looks like a typo (“PresentingPresent”). Renaming to something like isPresentingErrorViewController would improve readability and reduce confusion when maintaining this logic.

request(api:) is declared twice in this type with the same parameter list and only the return type differing (AnyPublisher<Void, Error> vs AnyPublisher<Void, ErrorResponse>). Swift can’t overload functions by return type alone, so this won’t compile. Please rename one of the methods (e.g., requestVoid / requestVoidWithErrorResponse) or collapse to a single error type and map at call sites.

requestWithResponse(api:) is also declared twice with identical parameters and only differing return type (AnyPublisher<T, Error> vs AnyPublisher<T, ErrorResponse>). This kind of return-type-only overloading won’t compile in Swift. Rename the methods or consolidate to a single failure type.

This second generic requestWithResponse(api:) duplicates the earlier definition with the same parameter list, differing only in the failure type. Swift cannot disambiguate by return type, so this must be refactored (e.g., different method names or a single failure type).

This file still constructs ErrorResponse(code:message:) in several places (e.g., network/multipart failures). With the newly added statusCode member (and no default/init), these initializers won’t compile. After stabilizing ErrorResponse’s initializer (e.g., default statusCode = nil), please re-check this file for remaining call sites.

createKeywordError uses the same message as deleteKeywordError ('키워드 삭제'). This makes the error misleading when keyword creation fails; adjust the message to reflect saving/creating the keyword.

Dictionaries can’t store nil values; keychains.updateValue(nil, forKey:) removes the key. This means the errSecItemNotFound path isn’t actually cached and read will query the Keychain again next time. If you want to cache misses, use a non-optional value type (e.g. enum) or track not-found keys separately.

removeAll predicate compares $0.professor == $0.professor, which is always true. This will delete every lecture matching classTime+name regardless of professor. Compare against lecture.professor instead (same as deleteLectureById).

PR description says this screen is a maintenance page shown on 5XX server errors, but the title/subtitle copy says '개발 중인 페이지입니다'. This looks like the wrong user-facing message for a 5XX maintenance scenario; update the copy to reflect server 점검/장애 안내.

isPresentingErrorViewController is set back to false inside the button completion before the error VC is dismissed. If another 5XX occurs during the dismissal animation, this can re-enter and attempt to present again. Consider resetting the flag in the dismissal completion (or after presentedViewController is actually dismissed) instead of immediately.